I still don't get it - what is the problem with moving the source to attic? It isn't valid source code any more - what is valid are the tags (/struts2/tags/STRUTS_2_3_8) but I doubt that anybody uses them (except us).
Wicket - very good example, I didn't know it isn't valid source code anymore (I have been checking it few times how they solved issues with SvnPubSub - I was waisting my time). There should be huge banner - MOVED-TO-GIT-DONT-USE-THIS-SOURCE! So, I opt to leave the source in attic and react if users start complaining about that. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2014/1/15 Rene Gielen <rene.gie...@gmail.com>: > I wonder what the downside is to just put svn subtrees in question into > read only mode compared to moving them to attic. As for placing a > prominent notice, such as MOVED-TO-GIT-README.txt, it would be useful to > our users in either case. > > Having a look at wicket, they just left svn at a point in time, keeping > everything in place (presumably read-only): > http://svn.apache.org/repos/asf/wicket/ > While I would wish to find a prominent README here as described above, a > see a case for not breaking things that are not in our hand. In the > early days of Weld / CDI e.g., I desperately needed trunk level builds > that were not published yet. For that reason I did a > checkout-and-build-dependency step in the maven bootstrap phase of my > build. While this was clearly violating the reproducible build > principle, I could live with this trade-off since the features I needed > were additions unlikely to go away. To some extent reproducibility may > be seen as that if you would checkout some project published a few years > ago, it would build without some early failures before javac even kicks > in. I know this is a corner case, but it would suffer from repo contents > (from which a checkout would be done during my build) being moved away. > > Regarding Apache policies, there are a few around that might help > finding a decision: > - Apache requires us to run on our own infrastructure for a single > reason: provide resources that will last for ages at the same place. > That is why we would not want to do canonical hosting of projects > externally, such as on GitHub - maybe it shuts down tomorrow? Unlikely, > yes. On the other hand, we have seen such things happen: tr.im URL > shortener was popular by it's time, but then money ran out. Each mailing > list posting containing tr.im URL you will look up in archive render > useless due to the URLs cannot be resolved any more. That's why Apache > even promotes their own URL shortener, http://s.apache.org. > - Dead projects, that is projects with dead communities, go to the Attic > meta project, including move of svn resources. While this has more to do > with having a meta-PMC for keeping oversight even if the owning PMC is > dead, it indeed involves moving of svn resources - AFAIK the only > process where such move happens as a part of an Apache policy. So moving > something to something called "attic" makes me shout out "I'm not dead > yet!" spontaneously :) > > So far, I would really tend to go into read-only mode with notices > placed in svn rather than to move things away. If there are good > arguments for the move I have missed so far, I would of course happily > switch my position on that topic. > > Just my 0.02$ > - René > > Am 15.01.14 20:54, schrieb Lukasz Lenart: >> 2014/1/15 Paul Benedict <pbened...@apache.org>: >>> The published POMs should all have a link to the SCM URL. We shouldn't move >>> to the attic so those links can stay valid. >> >> Ok, what is wrong if they become invalid? Maybe people start thinking >> about migration :-) >> >>> And what do you mean "cut the wire"? Is that an Apache directive to stop >>> people from going to svn? >> >> I don't know how it is in English - when child is born, connection >> with mother is cut :-) The same here, at some point we must strictly >> say - sorry guys! >> >> It was mentioned as a good practise from other projects which migrated to >> Git. >> >> >> Regards >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
