Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine what to do with the 'develop' branch #301

Closed
theacodes opened this issue Apr 19, 2017 · 11 comments
Closed

Determine what to do with the 'develop' branch #301

theacodes opened this issue Apr 19, 2017 · 11 comments
Assignees

Comments

@theacodes
Copy link
Member

@ddbeck the develop branch seems to be pretty stale now. Do we want to port anything over to master? Can we delete it to clean up?

@theacodes theacodes added state: needs clarification type: question A user question that needs/needed an answer labels Apr 19, 2017
@theacodes
Copy link
Member Author

Looking at the comparison. There's some really useful stuff here. I've independently sent a PR for travis in #300, but the contributing and style guide can be really useful.

@ddbeck
Copy link
Contributor

ddbeck commented Apr 19, 2017

@jonparrott I do think there's some things worth keeping from develop, but the overall decision to have a separate branch was a mistake. It was difficult to manage practically and it was kind of demotivating to work on that in isolation. Let's salvage the good stuff and then retire the develop branch.

I'm willing to do the work to make this happen and I can commit to spend time on this repo after Saturday and at least through to the following Sunday. But I'm not quite sure what the proper workflow would be. Sync up develop with master, then cherry pick some new PRs? A giant merge PR? Some of it is fairly complete and isolated from master (like the contributing and style docs), but the tutorial work is a bit iffy (maybe we could "hide" that in the ToC until it's more complete). If you have ideas on the best way to get us to something that we could get consensus on merging, I'll hop on it.

@theacodes
Copy link
Member Author

Personally for me it would be better to a new, separate PR based on master for the contributing and style guide (you can use cherry-pick for this). Then let's figure out what to do with the new tutorial content.

I'm thinking I'm gonna propose a new information architecture here -something along the lines of:

  • tutorials
    • setting up packaging tools
    • installing a package
    • creating a package
    • distributing a package
    • ...
  • reference
    • glossary
    • namespace packages
    • plugins
    • ...

@ddbeck
Copy link
Contributor

ddbeck commented Apr 19, 2017

OK, that sounds like a plan to me. I promise at least one PR on this no later than Sunday, April 30 (though maybe sooner—I'm traveling this week, so it's a little hard for me to predict).

Regarding IA, a long while back I wrote this proposed outline. It's old (so probably has some gaps) but sounds consistent with you've got in mind. It may serve as a good starting point.

@theacodes
Copy link
Member Author

OK, that sounds like a plan to me. I promise at least one PR on this no later than Sunday, April 30 (though maybe sooner—I'm traveling this week, so it's a little hard for me to predict).

Great. I'll review quickly. :)

Regarding IA, a long while back I wrote this proposed outline. It's old (so probably has some gaps) but sounds consistent with you've got in mind. It may serve as a good starting point.

This is great, thanks. I think it might still be useful, at least as an intermediate step, to separate out tutorial content vs reference content. Once we're there, we can start grafting documentation into a new TOC.

@theacodes
Copy link
Member Author

theacodes commented Jun 23, 2017

It seems the virtualenv and pre-reqs sections could still be useful. My thoughts are that I can create a folder called new-tutorials and not place it in the toctree, that way we can iterate on these new tutorials until we're ready to replace the existing packaging tutorial with our new set. WDYT @ddbeck? I can probably start writing the new packaging tutorial next week.

@ddbeck
Copy link
Contributor

ddbeck commented Jun 23, 2017

@jonparrott Yeah that sounds reasonable to me. Those already written sections need some work (they're pretty stilted for beginner material). If you want to start new-tutorials, then I'd be happy to do a pass on the content that's there. The sooner we get rid of the develop branch and have content we can iterate on publicly, the better, I think.

@theacodes
Copy link
Member Author

The new-tutorials directory has been added so we can start putting stuff in there whenever. https://github.com/pypa/python-packaging-user-guide/tree/master/source/new-tutorials

I've been a bit swamped but hopefully I can come up for air and start writing this stuff.

@theacodes theacodes self-assigned this Jul 28, 2017
@theacodes theacodes added component: tutorials and removed state: needs clarification type: question A user question that needs/needed an answer labels Jul 28, 2017
@pradyunsg
Copy link
Member

So, this issue would be resolved by trying to extract from develop -- whatever makes sense to -- and put them into the new-tutorials directory on master?

@theacodes
Copy link
Member Author

theacodes commented Aug 25, 2017 via email

@jeanas
Copy link
Contributor

jeanas commented Dec 13, 2023

I'm going to close this isse; the PUG and the packaging landscape in general have changed so much over 7 years that salvaging material from this branch would be hard at this point (although the branch remains in the repository).

@jeanas jeanas closed this as completed Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants